Asynchronous transfer of messages between application programs running different data processing systems within a network is well known in the art, and is implemented by a number of commercially available messaging systems. These systems include IBM Corporation's WebSphere® MQ family of messaging products, which use asynchronous messaging via queues. A sender application program issues a PutMessage command to send (put) a message to a target queue, and a queue manager handles the complexities of transferring the message from the sender to the target queue, which may be remotely located across a heterogeneous computer network. A message broker may of course process a received message prior to the transferring the message. (IBM and WebSphere are trademarks of International Business Machines Corporation).
The receipt and processing of a message by a typical messaging system is illustrated in FIG. 1.
For a message broker 10 to be able to process a message 40, it is necessary for processing software 20 within the broker to access parts of that message. Messages are accessed and processed as a series of actions, represented as nodes (execution units), on the message to either route the message to further processing steps or to put data into or get data out of the message. This series of actions is typically known as a message flow and may comprise input, output and also processing nodes such as compute and transformation nodes.
Before the message can be accessed and processed by such a message flow, however, the content of the message must be in an accessible format. Products such as WebSphere MQ Integrator Broker provide a logical, abstract layer for accessing the content of a message and for converting the physical representation of the message into a logical view suitable for processing by the message flow. This physical to logical conversion is typically done by a message parser(s) 30 (one shown), which retrieves a part of the message and then interprets its content. In most cases, the interpretation is based on a message structure definition from a message definition repository 60. The output of the conversion process is a logical representation (e.g. a graph or tree structure 50 comprising a plurality of nodes) representing each part of the message.
Using the graph 50, processing nodes of a message flow may for example access parts of a message to extract values therefrom in order to update a local database 70.
FIG. 2 illustrates the graph structure 50 in more detail.
A message 100 typically comprises multiple parts (e.g. parts 1, 2, 3 and 4) and each part typically comprises multiple fields. By way of example, parts 1 and 2 may include header information, whilst parts 3 and 4 may include business information.
A different parser is typically responsible for extracting the relevant information from each part and for converting this information into a graph structure.
Each message part is represented in the graph structure as a part node 110. Below each part node, there are a plurality of field nodes 120 representing the information stored within each message part.
In many cases, the information in the simple graph structure illustrated is not enough. Frequently the processing of a message needs some additional context information, e.g. configuration information that allows a customer to dynamically influence the processing of a message, or directory information that is required to check validity of a message. Such context information is typically stored within a context store associated with the messaging system and is used by the appropriate message flow to determine how the message should be processed. In most cases, this information must not be modified by the message flow.
To get such context information into the message flow when needed, there are currently a number of possible solutions.
Solution 1: At any time when context information is required by the messaging flow, a processing node in the message flow retrieves the necessary information from the context store. Thus, in this solution, processing nodes in the flow are provided with the functionality necessary to retrieve the appropriate context information. Having retrieved the appropriate context information, the subsequent processing in the node can then perform the required operation using the retrieved information—e.g. comparing the information with parts of the message or inserting the context information into the message. Using this method, the information is always retrieved when needed and is therefore up-to-date. The disadvantage is that when the same context information is needed by different nodes in the message flow, the same information must be retrieved multiple times.
Solution 2: Another solution is to use a processing node in the message flow that retrieves the information from the context store and adds this information to the message. In this way, the information is passed to subsequent processing nodes in the message flow such that they too can access the information when needed for the processing of the message in question.
The method of solution 2 is advantageous since the information need be retrieved only once, even if it is needed multiple times in multiple nodes in the message flow or for the processing of multiple messages. The context information is held by the processing node in its physical form in a cache and added in its logical form into every appropriate message. Further, this solution is advantageous because the context information is consistent within the execution of one message.
FIG. 3 illustrates, in accordance with the prior art, a message graph including retrieved context information. When context information is needed by a processing node within a message flow, the appropriate information is extracted from the context store and the logical view of the message is augmented with this context information. This is shown in FIG. 3 as element 130 (apart from element 130, it will be appreciated that FIGS. 2 and 3 are identical.)
The disadvantage of this method is that the message flow is modified (at runtime), as is the message itself. Once a message flow has processed a message, each parser streams the logical view of its part of the message back into a physical representation. Since the logical view of the message has been modified, the physical view as re-constructed by the appropriate parsers will also have changed.